TED — Turbine  Engine  Diagnostics 

Richard  Helfman 
John  Dumer 
Timothy  Hanratty 


ARL-TR-856 


September  1995 


DTIC 

ELECTE 

OCT  1  2  1995] 

G 


1W51011 065 

APPROVED  FOR  PUBLIC  RELEASE;  DISTRIBUTION  IS  UNLIMITED. 

^TrrY  INSPECTED  Q 

DTI®  QUAIjITY 


NOTICES 


Destroy  this  report  when  it  is  no  longer  needed.  DO  NOT  return  it  to  the  originator. 


Additional  copies  of  this  report  may  be  obtained  from  the  National  Technical  Information 
Service,  U.S.  Department  of  Commerce,  5285  Port  Royal  Road,  Springfield,  VA  22161. 


The  findings  of  this  report  are  not  to  be  construed  as  an  official  Department  of  the  Army 
position,  unless  so  designated  by  other  authorized  documents. 


The  use  of  trade  names  or  manufacturers’  names  in  this  report  does  not  constitute 
indorsement  of  any  commercial  product. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  this  confection  of  Information  ta  MtimttM  to  averags  1  hour  par  responM,  including  the  time  foe  reviewing  Instruction*,  Marching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  Information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  Information,  Including  suggestion*  for  reducing  this  burden,  to  Washington  headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Hktiwav.  Suite  1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget  Paperwork  Reduction  Proiecti07tt4-0188),  Washington.  DC  20503. 

2.  REPORT  DATE  I  3.  REPORT  TYPE  AND  DATES  COVERED 

September  1995  Final _ 


4.  TITLE  AND  SUBTITLE 

5.  FUNDING  NUMBERS 

TED-Turbine  Engine  Diagnostics 

4B010  503  350000 

6.  AUTHOR(S) 

Richard  Helfman,  John  Dumer,  and  Timothy  Hanratty 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESSES) 

U.S.  Army  Research  Laboratory 

ATTN:  AMSRL-SC-II 

Aberdeen  Proving  Ground,  MD  21005-5067 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

ARL-TR-856 

9.  SPONSORING/MONITORING  AGENCY  NAMES(S)  AND  ADDRESSES) 

1 0.SPONSORING/MONFTORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

13.  ABSTRACT  (Maximum  200  words) 

TED  (turbine  engine  diagnostics)  is  a  diagnostic  expert  system  to  help  the  Ml  Abrams'  mechanic  find  and  fix 
problems  in  the  AGT1500  turbine  engine.  TED  was  designed  and  built  by  the  U.S.  Army  Research  Laboratory  and 
the  U.S.  Army  Ordnance  Center.  Limited  fielding  was  begun  in  July  1994  to  selected  National  Guard  units,  with 
eventual  fielding  to  28  National  Guard  units.  Active  units  of  the  U.S.  Army  will  receive  TED  in  January  1996. 
Several  foreign  countries  are  expected  to  use  TED  for  their  Ml  tank  maintenance.  TED  was  designed  to  provide  the 
apprentice  mechanic  the  ability  to  diagnose  and  repair  the  turbine  engine  like  an  expert  mechanic.  The  U.S.  Army 
Ordnance  Center  has  estimated  that  TED  will  save  more  than  $8  million  annually  by  enhancing  the  Ml  mechanic’s 
diagnostic  capabilities. 


NSN  7540-01-280-5500  Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  239-18  298-102 


14.  SUBJECT  TERMS 


diagnostic,  turbine  engine,  expert  system 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

UNCLASSIFIED 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

UNCLASSIFIED 


15.  NUMBER  OF  PAGES 

15 _ 

16.  PRICE  CODE 

20.  LIMITATION  OF  ABSTRACT 

UL 


12a.  DISTRIBUTiON/A  VAIL  ABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 


12b.  DISTRIBUTION  CODE 


1.  AGENCY  USE  ONLY  (Leave  blank) 


J 


Intentionally  left  blank. 


Table  of  Contents 


1 .  Introduction . 

2.  Background  . 

2.1  Turbine  Engine  Maintenance  Costs 

2.2  Maintenance  Doctrine . 

2.3  Free  Spare  Parts . 

2.4  Computers  on  the  Battlefield . 

2.5  Paperless  Battlefield . . 

2.6  The  Ml  Forever . 

3.  TED  History  and  Timetable . 

4.  Approach . 

4. 1  Establish  and  Maintain  Communication. 

4.1.1  Learn  What  the  User  Does . 

4.1.2  Rapid  Prototyping . 

4.2  Spiral  Model . 

4.3  Extensive  User  Involvement  . 

4.4  Tracking  Hardware  and  Software  Trends 

4.5  Early  and  Frequent  Testing  of  Software  . 

5.  Software  Selection . 

6.  Reasoning  in  TED  . 


1 

1 

1 

1 

2 

2 

2 

2 

2 

3 

3 

3 

3 

3 

4 
4 
4 

4 

5 


m 


7.  TED  Software  Overview  ... 

7.1  Design  Goals . 

7.2  Soldier  Interface.  . . 

7.3  A  Brief  Tour  of  TED 

8.  Formal  User  Test . 

9.  Related  Efforts . 

10.  Future  Efforts . 

1 1 .  References  . 

Distribution  List . 


.6 

.6 

.6 

.6 

.8 

.8 

.9 

.9 

11 


Accesion  For 

NTIS  CRA&J 
DTIC  TAB 
Unannounced 
Justification 


By 

Distribution  / 

Availability  Codes 

Dist 

B± 

Avail 

Spc 

and/or 

icial 

IV 


List  of  Figures 


1.  Maintenance-Level  Military  Structure . 1 

2.  Spiral  Model . 4 

3.  Sample  page  from  TM  . 5 

4.  Main  Menu  Screen  . . 6 

5.  Preliminary  Analysis  Screen . 7 

List  of  Tables 

1 .  Preliminary  Test  Results . 8 


v 


INTENTIONALLY  LEFT  BLANK. 


VI 


1.  Introduction 

The  Gulf  War  confirmed  what  the  U.S.  Army 
armor  community  realized  long  ago —  the  Ml  Abrams 
main  battle  tank  epitomizes  lethality  and  survivability 
on  today’s  battlefield.  Unfortunately,  there  is  a  negative 
corollary,  which  is  well  known  to  the  Army  logistics 
community:  the  Ml  is  expensive  to  operate,  support, 
and  maintain.  While  many  Army  organizations  are 
responsible  for  ensuring  operational  readiness  of  the 
fleet,  it  is  the  direct  support  (DS)  mechanic  who 
ensures  the  U.S.  Army's  new  maintenance  philosophy 
to  Fix  Forward.  Combined  with  the  Army's 
downsizing  and  skill  consolidation  efforts,  the  tasks  of 
the  DS  mechanic  are  becoming  increasingly  more 
difficult.  He  is  being  asked  to  do  more  with  less. 

Recognizing  these  facts,  the  U.S.  Army  Ordnance 
Center  (USAOC),  in  conjunction  with  the  U.S.  Army 
Research  Laboratory  (ARL),  has  focused  research 
efforts  to  provide  the  DS  mechanic  with  new 
maintenance  capabilities.  The  project  began  in  1991, 
with  the  goal  of  providing  the  DS  mechanic  the  best 
possible  diagnostic  and  maintenance  tools  for  the  Ml 
turbine  engine.  The  result  of  the  combined  effort  is  the 
development  of  a  diagnostic  expert  system,  known  as 
TED  (turbine  engine  diagnostics).  TED  assists  the  DS 
mechanic  in  effectively  diagnosing  and  repairing  the 
Ml  Abrams  turbine  engine.  Although  TED  is  still  an 
ongoing  project,  with  final  delivery  due  in  January 
1996,  the  National  Guard  Bureau  has  asked  for  early 
fielding  of  the  completed  modules.  This  fielding  to 
National  Guard  units  began  in  July  1994  and  continues. 

2.  Background 

By  1 99 1 ,  many  factors  were  converging  toward  the 
need  for  a  better  maintenance  system  for  the  Ml 
turbine  engine.  The  USAOC,  responsible  for 
maintaining  all  Army  ground  vehicles,  asked  ARL  to 
join  in  a  collaborative  effort  to  improve  Ml  turbine 
maintenance. 

2.1  Turbine  Engine  Maintenance  Costs 

The  Ml  Abrams  tank  is  the  Army’s  main  weapon 
system,  with  more  than  7500  tanks  fielded  to  active  and 
reserve  units.  The  AGT1500  turbine  engine  takes  the 
biggest  slice  of  the  maintenance  budget.  For  instance, 
one  study  concluded  that  "the  maintenance  cost  of  the 
AGT-1500  engine  represents  the  largest  portion  of  the 


Army  AGT-1500  operation  and  support  (O&S)  costs. 
These  costs  are  $95.00  per  operating  hour  (Textron, 
1988).”  Another  study  determined  that  in  1  year,  out  of 
1  group  of  360  engines  evacuated  to  depot,  39%  of 
them  were  reported  as  "no  evidence  of  failure" 
(NEOF).  The  NEOF  condition  means  that  an  engine 
was  pulled  from  the  tank,  sent  back  to  the  depot  for 
repair,  but  the  depot  determines  there  is  nothing  wrong 
with  the  engine.  The  unnecessary  cost  related  to  NEOF 
conditions  was  estimated  at  $18.2  million  annually 
(Textron,  1989). 

2.2  Maintenance  Doctrine 

Maintenance  in  the  Army  is  accomplished  at  as 
many  as  four  levels.  The  first  is  called  organizational 
or  unit  level.  This  is  company  level  maintenance. 
Items  that  cannot  be  fixed  at  the  company  are  sent  to 
the  next  level,  called  direct  support.  Direct  support  is 
usually  at  brigade  or  battalion.  The  next  level  above 
direct  support  is  called  general  support  (GS).  This 
would  normally  be  at  division.  The  final  level  is  called 
depot.  For  the  AGT1500  turbine,  there  is  often  no 
general  support  maintenance.  Engines  that  cannot  be 
fixed  at  DS  are  sent  to  depot,  and  depot  is  usually  in  the 
U.S.  (See  Figure  1.) 


Figure  1:  Maintenance-Level  Military  Structure 


The  TED  project  focused  on  DS-level  maintenance 
for  several  reasons.  First,  the  DS  shop  determines 
whether  an  engine  should  be  sent  to  depot  for  repair, 
and  this  decision  is  expensive  (~  $450,000  per  engine). 
Second,  the  DS  shop  recently  under  went  a  major 
change  in  maintenance  doctrine.  Previously,  when  an 
engine  failed  at  organization,  the  entire  tank  was 
evacuated  to  the  DS  unit  for  repair.  Under  the  new 
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doctrine,  when  an  engine  fails,  it  is  pulled  from  the 
tank  and  sent  to  DS.  The  tank  hull  remains  at  the  unit, 
a  new  engine  is  sent  forward,  and  the  tank  is  quickly 
returned  to  full  operational  status.  However,  at  the  DS 
shop,  without  the  tank,  there  was  no  way  to  start  the 
engine.  So  new  equipment,  called  the  ground  hop 
support  set  (GHSS),  was  designed  and  fielded  to  the 
DS  shop.  The  GHSS  replicates  the  missing  functions 
of  the  tank:  fuel,  battery,  driver’s  instrument  panel,  and 
electronic  control  unit  (ECU).  New  maintenance 
procedures  and  new  manuals  were  necessary  to 
accompany  this  change. 

Third,  the  DS  shop  has  now  been  authorized  to 
perform  repairs  previously  done  at  GS  or  depot.  This 
new  maintenance  concept  is  called  Fix  Forward.  The 
new  DS  organization  was  initially  called  DS  Plus  to 
distinguish  it  from  the  original  DS  concept.  The  "Plus" 
has  now  been  dropped.  Under  the  new  DS  concept,  the 
mechanic  can  now  perform  repairs  previously  not 
authorized.  Along  with  the  new  authorized  tasks  come 
new  tools  previously  available  only  at  higher 
maintenance  levels  and  new  lists  of  spare  parts  that  can 
be  ordered  at  the  DS  level.  There  are  no  manuals  for 
the  new  DS  tasks. 

2.3  Free  Spare  Parts 

In  the  past,  spare  parts  were  free!  If  you  were  a 
company  commander,  and  one  of  your  tanks  failed,  it 
was  fixed  for  free  (as  far  as  you,  the  commander,  were 
concerned).  Today,  as  that  same  commander,  you  are 
billed  for  your  maintenance  costs.  The  new  doctrine  is 
called  stock  funding  of  depot-level  repairables 
(SFDLR),  and  the  hope  is  that  it  will  reduce  overall 
maintenance  costs,  without  adversely  affecting  unit 
readiness.  Fortunately,  the  Army  realized  that  SFDLR 
alone,  without  better  maintenance  aids  for  the 
mechanic,  was  not  the  final  answer  to  reducing  high 
maintenance  costs. 

2.4  Computers  on  the  Battlefield 

The  Army  is  supplying  computers  to  its 
mechanics.  These  computers  are  part  of  the  Army 
common  hardware,  and  are  called  the  contact  test  set 
(CTS)  III.  CTS  III  is  a  DX-33  MHZ  or  DX-50  MHZ 
80486  processor  that  employs  8  megabytes  (MB)  of 
RAM  and  either  a  200-  or  500-MB  hard  disk  drive.  It 
is  capable  of  running  either  the  SCO  Unix  Operating 
System  or  Microsoft  DOS  6.2  with  Windows  3.1.  The 


goal  is  to  field  CTS  III  to  every  team  of  mechanics  as 
part  of  the  GHSS. 

2.5  Paperless  Battlefield 

As  computers  become  more  prolific  and  handle 
more  data  and  information,  the  concept  of  the  digital 
battlefield  has  become  more  popular.  The  idea  is  that 
all  information  will  be  in  digital  format  and  will  be 
stored,  processed,  and  distributed  by  computers.  Thus, 
the  need  for  paper-based  information  is  at  least 
lessened  and  perhaps  eliminated.  For  the  mechanic, 
this  means  that  all  information  currently  available  in 
paper  format  in  the  technical  manuals  (TMs),  may  soon 
be  available  in  digital  format  on  floppy  disks,  CD- 
ROMs,  or  on  a  removable  hard  drive.  The  goal  of 
putting  computers  in  the  field  is  a  reality;  the  goal  of 
the  paperless  Army  is  not  quite  so  near. 

2.6  The  Ml  Forever 

The  Ml  tank  will  remain  in  the  Army  inventory 
for  a  very  long  time.  There  are  no  plans  or  funds  to 
replace  the  Ml  within  the  foreseeable  future.  The 
reserve  units  are  just  now  retiring  their  M60  tanks  and 
are  switching  to  Mis.  It  is  likely  that  the  reserve  units 
will  keep  their  Ml  tanks  for  at  least  another  15  years. 

3.  TED  History  and  Timetable 

The  TED  program  started  in  1991  at  the  USAOC 
as  an  effort  to  seek  solutions  to  some  of  the 
maintenance  problems  the  Army  was  having  with  its 
equipment.  ARL  joined  the  program  in  the  summer  of 
1991  as  knowledge  engineers  and  technical  advisors, 
with  the  USAOC  supplying  subject  matter  experts 
(SMEs)  to  provide  the  expert  diagnostic  knowledge  and 
to  guide  the  development  direction  of  the  system.  The 
USAOC  also  supplied  engines  and  soldiers  as  needed 
to  test  the  new  software  being  developed. 

The  first  TED  prototype  was  ready  by  January 

1992.  For  the  next  18  months,  existing  modules  were 
expanded  and  new  modules  were  begun.  By  August 

1993,  the  program  was  sufficiently  developed  to 
warrant  formal  testing.  The  first  formal  field  test  was 
conducted  in  August  1993.  Section  8  contains  the 
details  of  that  test. 

In  January  1994,  Project  Manager- Abrams  (PM- 
Abrams),  the  primary  proponent  for  the  Abrams  tank, 
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met  with  members  of  the  TED  team.  Two  crucial 
questions  were  discussed:  a)  Would  the  TED  program 
succeed?,  and  b)  If  so,  how  long  would  it  take  to 
finish?  All  agreed  the  project  would  succeed,  and  a 
target  date  of  completion  of  January  1996  was  given. 
With  that,  PM- Abrams  decided  to  field  TED  in  January 
1996  to  all  active  DS  units  with  Ml  tanks.  In  addition, 
further  production  of  paper  manuals  for  the  AGT1500 
engine  was  halted.  The  decision  was  made  that  TED 
would  be  the  diagnostic  system  for  the  Ml  turbine 
engine. 

In  March  of  1994,  the  National  Guard  Bureau 
asked  to  have  TED  for  its  National  Guard  units  as  soon 
as  possible.  They  wanted  TED  before  it  was  finished, 
reasoning  that  even  a  partial  TED  would  save  them 
maintenance  dollars.  Fielding  to  the  first  two  National 
Guard  units  (Georgia  and  Tennessee)  began  in  July 
1994.  (Note  that  TED  saved  both  states  roughly 
$50,000  in  its  first  2  days  of  operation.)  The  National 
Guard  Bureau  continues  to  field  TED  at  the  rate  of  2  to 
3  states  per  month,  until  all  28  states  with  Ml  tanks 
have  the  TED  software. 

As  mentioned  above,  the  Army  will  field  TED  in 
January  1996  to  every  active  Ml  DS  unit 
(approxmately  200  sites).  At  least  two  foreign 
countries  have  agreed  to  use  TED  for  their  Ml  DS 
engine  maintenance. 

4.  Approach 

The  TED  programmers  quickly  established  some 
important  project  guidelines  that  remain  in  effect  today. 

4.1  Establish  and  Maintain  Communication. 

Programmers  and  SMEs  do  not  speak  the  same 
language.  Programmers  talk  of  frames  and  objects, 
CARS  and  CDRS.  Ml  mechanics  talk  of  inlet  guide 
vane  (IGV)  angles,  and  of  rotational  variable 
differential  transformers  (RVDTs).  Each  needs  to  learn 
some  of  the  other's  language,  but  the  main  effort  is  on 
the  programmer  to  learn  the  language  of  the  mechanic. 

4.1.1  Learn  What  the  User  Does. 

The  best  way  to  do  this  is  to  observe  the  user  in  his 
environment.  The  TED  team  attended  and  videotaped 
classes  for  Ml  mechanics.  This  produced  three 
important  benefits.  First,  it  quickly  immersed  the 


programmers  into  the  language  of  the  mechanic.  The 
IGV  is  located  in  front  of  the  engine  and  the  angle 
determines  how  much  air  gets  through  to  the  turbine 
blades.  Second,  it  gave  an  accurate  picture  of  how  a 
mechanic  performs  his  job  and  how  software  might 
improve  that  job.  The  TED  team  noticed  during  the 
first  session  that  the  original  scope  of  work  was  too 
narrow.  There  was  a  whole  suite  of  software  that  could 
help  the  mechanic  better  perform  his  job.  Third,  it 
established  a  bond  between  programmer  and  soldier. 
Soldiers  could  sense  that  the  team  was  serious  and  that 
soldiers'  needs  would  be  given  serious  attention.  They 
were  thus  eager  to  cooperate. 

4.1.2  Rapid  Prototyping. 

A  prototype  is  essential  for  two-way 
communication.  It  allows  the  user  to  see  and  touch 
what  the  programmer  envisions  for  the  user.  It  gives 
the  user  the  earliest  opportunity  to  comment  on  his 
system,  and  it  gives  him  some  clue  as  to  the  potential  of 
the  project.  The  user  does  not  always  know  what 
technology  is  available,  and  the  hands-on  experience  of 
the  prototype  is  often  the  best  way  educate  the  user.  A 
prototype  serves  as  a  common  reference  point;  without 
it,  not  much  useful  feedback  can  occur.  It  also  shows 
how  well  the  programmer  understands  the  user's  needs. 

4.2  Spiral  Model 

Boehm's  spiral  model  (Boehm,  1986)  incorporates 
an  incremental  development  schema.  Successive 
prototypes  are  produced  that  expand  user  requirements. 
In  addition,  the  programmer  is  able  to  break  complex 
tasks  into  smaller  components.  As  each  component  is 
developed,  it  is  evaluated  against  user  requirements. 
The  user  requirements  are  re-evaluated  as  each 
successive  module  is  developed.  Consequently,  the 
user  is  an  integral  part  of  the  development  team.  His  or 
her  input  is  essential. 

There  are  many  reasons  why  the  team  adopted  the 
spiral  method  for  the  TED  program.  One  was  the  fast 
paced  changes  occurring  in  PC  hardware  and  software. 
It  was  an  easy  guess  in  1991  that  hardware  and 
software  for  the  PC  would  continue  to  improve  and 
become  more  affordable.  Computer  memory  continues 
to  expand  and  deflate  in  price.  Hard  drives  continue  to 
get  bigger  and  cheaper.  Screen  resolution  expands  and 
video  cards  improve.  The  price  of  a  Pentium  system 
today  rivals  the  price  of  a  386  system  in  1991 .  Software 
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has  followed  a  similar  pattern.  Every  year  software 
improves,  new  products  are  announced,  and  existing 
products  offer  upgrades  at  an  astounding  pace  and 
more  reasonable  prices. 

The  second,  and  partially  related,  reason  to  use  an 
iterative  approach  is  that  the  user,  at  the  start  of  a 
project,  can  rarely  envision  how  technology  can 
improve  his  or  her  job.  A  system  based  on  initial  user 
expectations  will  at  best  be  shallow,  and  may  even  be 
useless.  The  programmer  and  the  SME  are  each 
constantly  learning  about  the  other.  The  programmer 
is  continually  learning  about  the  needs  and  duties  of  the 
mechanic,  and  the  mechanic  is  learning  about  the 
potential  impact  of  new  software  on  his  future. 


4.3  Extensive  User  Involvement 

When  the  aim  is  to  produce  software  that  not  only 
works  as  planned  but  also  gets  used  by  the  mechanic, 
then  user  participation  in  the  development  process  is 
critical.  The  TED  team  heard  many  stories  from 
soldiers  about  equipment  that  never  gets  used  and 
about  equipment  that  is  difficult  to  use  for  which  a 


small  change  would  have  made  the  item  soldier 
friendly,  to  combat  these  difficulties,  TED  SMEs 
were  assigned  full  time  to  the  project.  The  benefits 
gained  as  a  result  of  their  early  and  continued 
participation  were  paramount. 

4.4  Tracking  Hardware  and  Software  Trends 

This  complements  the  iterative  approach  in  that 
goals  that  were  impossible  or  difficult  in  the  past  may 
now  be  relatively  easy  tasks.  The  TED  team  continues 
to  meet  formally  once  a  month  to  decide  the  direction 
and  scope  of  the  project.  Unsatisfied  goals  are  re¬ 
evaluated,  and  some  may  be  dropped  from  the  list, 
while  new  goals  may  be  added. 

4.5  Early  and  Frequent  Testing  of  Software 

In  the  early  years  of  the  project,  the  software  was 
tested  at  least  weekly  using  students  in  the  USAOC. 
After  the  first  formal  test  in  August  1993,  the  need  for 
testing  was  relaxed  and  is  now  done  once  a  month 
using  students  from  the  USAOC.  Additional  user 
feedback  is  also  provided  monthly  from  the  National 
Guard  units  that  have  received  TED.  Feedback  from 
users  may  lead  to  small  easy  changes  to  the  system,  or 
it  may  lead  to  new  system  features  or  to  new  software 
modules. 

5.  Software  Selection. 

The  Army  had  already  chosen  the  hardware  for 
TED,  the  CTS  III,  which  was  capable  of  running  Unix, 
DOS,  or  Windows.  It  was  clear  from  the  beginning 
that  the  project  would  involve  a  variety  of  tasks,  each 
needing  a  specialized  software  package.  It  was  also 
clear  that  no  package  could  run  in  isolation.  Programs 
would  need  to  exchange  information  with  others. 
Windows  was  chosen  as  the  operating  system  because 
of  its  capabilities  and  its  perceived  growth  potential. 

For  any  software  choice,  the  key  is  to  choose  a 
package  that  first  meets  the  user's  needs  and  then,  if 
possible,  the  programmer's.  One  choice  the 
programmer  must  often  make  is  whether  to  choose 
commercial  off-the-shelf  (COTS)  packages  or  whether 
it  is  better  to  write  the  code  him  or  herself.  Today, 
COTS  packages  offer  many  advantages  in  comparison 
to  code  produced  in  house. 
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These  benefits  include 

-  Cost  is  reduced  by  spreading  among  many. 

-  Code  is  already  written,  saving  time. 

-  Technology  proliferation  offers  many  selections. 

-  External  support  is  available  from  the 
developer. 

The  disadvantages  may  include 

-  The  program  may  not  fit  the  problem. 

-  It  is  tied  to  the  survivability  of  the  developer. 

-  While  code  may  initially  work,  subsequent 

upgrades  may  not. 

-  Possible  high  run-time  fees. 

The  TED  team  prefers  to  use  COTS  software  when 
available  and  suitable.  Whenever  such  software  is  not 
available  or  suitable,  the  choice  is  to  wait  until  a  new 
product  is  released  or  a  product  upgrade  provides  the 
needed  functionality,  or  write  the  code  in  house.  For 
example,  the  current  hypertext  package  was  not  chosen 
until  the  Fall  of  1993,  and  the  data  base  was  not 
selected  until  the  Fall  of  1994. 

These  code  decisions  are  subject  to  change  at  each 
monthly  meeting.  As  the  team  gathers  experience  with 
a  package  or  code,  the  decision  might  be  to  continue  as 
before,  to  switch  from  in-house  to  COTS  (or  vice 
versa),  or  to  switch  COTS  vendors. 

6.  Reasoning  in  TED 

The  main  diagnostic  software  in  TED  is  a 
Windows-based  shell  called  Adept  from  SoftSell. 
Adept  is  based  on  a  reasoning  paradigm  called 
Procedural  Reasoning  System  (PRS)  (Georgeff  and 
Lansky,  1983  and  1986).  PRS  is  a  visual  method  of 
encoding  reasoning  strategies  used  by  expert  problem 
solvers.  The  knowledge  is  represented  graphically  with 
semantics  suited  to  the  procedural,  goal-oriented  style 
of  problem  solving,  and  PRS  is  best  suited  for  problems 
that  are  both  procedural  and  goal-oriented.  A 
procedural  approach  uses  an  ordered  step-by-step 
prescription  to  obtain  a  desired  result,  possibly 
including  alternate  paths  in  case  of  failure.  Such  an 
approach  is  also  goal  oriented  if  some  steps  are  goals  to 
be  achieved  rather  than  specific  actions  to  be 
performed  (ADS  working  paper,  1988). 


Army  TMs  closely  follow  this  paradigm.  They  are 
often  graphical  in  nature  with  decision  trees  displayed 
on  the  page.  Some  nodes  represent  goals  to  be 
achieved;  others  represent  specific  tasks  to  be 
performed.  These  tasks  can  themselves  become  goals 
whose  solution  is  to  be  given  on  another  page  (or  in 
another  manual).  See  Figure  3  for  a  sample  page  from 
the  engine  manual  (TM  9-2835-255-34  Page  3-20). 


SYMPTOM  2 


3-20 


Figure  3:  Sample  page  from  TM 

PRS  combines  features  from  several  programming 
paradigms.  Like  PROLOG,  it  has  goal-directed 
inferencing  and  depth-first  search.  Like  expert  system 
shells,  it  provides  a  frame  system  for  global  objects. 
Like  LISP,  it  is  well  suited  for  rapid  prototyping. 

SMEs  quickly  learned  how  to  read  Adept's  visual 
code,  and  some  began  writing  their  own  code  or 
modifying  code  written  by  the  knowledge  engineers. 
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7.  TED  Software  Overview 
7.1  Design  Goals. 

At  about  6  months  into  the  project,  the  SMEs  had 
established  several  design  goals.  These  goals  were 
based  primarily  on  each  SME’s  extensive  experience  as 
an  Ml  mechanic  and  as  an  Ml  instructor  for  engine 
maintenance  classes.  The  SMEs  had  much  previous 
experience  with  soldier  mechanics-their  likes  and  then- 
dislikes.  The  following  lists  the  main  design  goals  for 
the  TED  software.  The  software  should  be 

-  accurate, 

-  easy  to  use, 

-  flexible, 

-  task  oriented,  and  it  should 

-  support  multiple  levels  of  expertise. 

First,  the  software  should  be  accurate.  It  need  not 
be  perfect,  but  it  should  be  significantly  better  at 
diagnosing  faults  than  the  system  it  is  replacing. 
Otherwise,  it  will  lose  soldier  respect  and  it  will  not  be 
used.  Second,  it  must  be  easy  to  use,  for  otherwise,  it 
will  sit  on  the  shelf.  Mechanics  have  favorite  stories  of 
diagnostic  equipment  that  does  nothing  but  occupy  lots 
of  storage  space.  Third,  it  must  be  flexible  enough  to 
support  a  variety  of  diagnostic  styles.  For  example, 
some  mechanics  are  thorough  and  methodical,  and  a 
structured  step-by-step  approach  is  best  for  them.  A 
few  have  a  sixth  sense  and  "know"  what  is  wrong  with 
an  engine.  They  have  only  limited  need  for  the 
information  in  TED  and  will  only  use  it  as  an 
occasional  reference.  Other  soldiers  are  a  mixture  of 
styles.  They  may  know  a  lot  about  some  parts  of  the 
engine  but  need  guidance  in  other  areas. 

The  fourth  goal  is  that  TED  be  task  structured  in  a 
way  that  is  natural  for  the  soldier.  The  current  TMs 
have  a  structure  that  is  difficult  to  use  and  to  follow. 
Consider  the  example  shown  in  Figure  3.  The  task  is  to 
determine  whether  excessive  metal  chips  are  present. 
To  perform  this  check,  the  user  must  first  find  the 
correct  TM,  which  isTM-34.  Once  in  the  right  TM,  the 
job  is  to  find  the  correct  page.  "Symptom  2,  Metal 
Chips,  begins  on  page  3-20,  seen  from  Figure  3,  the 
tasks  for  Symptom  2,  Metal  Chips  Found,  refer  to  tasks 
in  TM  20-1  and  in  TM  34-1."  However,  little 
information  is  given  as  to  which  page  in  TM  20-1  or 
TM  34-1  to  consult.  Experts  can  navigate  the  TMs,  but 
others  find  the  structure  confusing. 


The  last  goal  recognizes  that  mechanics  come  with 
different  skill  levels.  Experts  need  little  or  no  help 
from  TED.  Beginners  need  extensive  step-by-step 
instructions.  A  system  aimed  at  just  one  level  of 
expertise  would  bore  the  expert  and  baffle  the  beginner. 

7.2  Soldier  Interface. 

Users  communicate  with  TED  primarily  through 
the  mouse,  and  sometimes  through  keyboard  input.  At 
the  top  level,  TED  is  menu  driven.  At  this  level,  the 
soldier  can  choose  which  module  to  run  (described  in 
the  next  section).  Inside  a  module,  TED  can  be  either 
soldier  driven  or  data  driven. 

Soldier  driven  means  that  TED  is  in  browse  mode. 
This  is  the  equivalent  of  opening  the  TM  to  any  section 
and  reading  the  pages.  Browse  mode  is  useful  for 
experts  who  need  little  supervision  and  only  occasional 
help  from  the  TMs. 

In  data-driven  mode,  TED  first  reads  its 
knowledge  base  to  determine  engine  history  and  then 
leads  the  mechanic  through  a  series  of  tasks  to  perform 
and/or  questions  to  answer.  All  pertinent  information  is 
linked  so  the  user  is  automatically  led  through  different 
sections  of  the  TMs,  if  necessary.  The  user  can  leave 
this  mode  at  any  time  and  go  into  browse  mode. 


7.3  A  Brief  Tour  of  TED 


Figure  4:  Main  Menu  Screen 


From  TED's  main  menu  (see  Figure  4),  mechanics 
can  access  troubleshooting  and  maintenance  tasks. 
They  can  also  access  the  repair  parts  special  tool  list 
and  special  applications  such  as  diagnostic  intelligent 
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tutoring  systems  (DITS)  and  automatic  breakout  box 
(ABOB).  The  troubleshooting  tasks  are  further  broken 
into  specific  areas  such  as  preliminary  analysis, 
troubleshooting  by  symptom,  and  protective  mode 
troubleshooting.  Each  of  these  features  is  discussed 
below. 

o  Preliminary  Analysis  (PA).  The  PA  module  guides 
mechanics  through  a  series  of  detailed  inspections  of 
the  engine.  The  engine  is  divided  into  separate 
inspection  stations,  and  at  each  station,  PA  guides 
mechanics  through  a  100%  inspection  of  that  region. 
It  accomplishes  this  by  using  graphics,  photographs, 
and  an  easy-to-read,  step-by-step  layered  instructional 
format.  See  Figure  5  for  a  sample  screen.  It  is 
designed  to  assist  mechanics  with  different  levels  of 
experience  through  a  series  of  YES,  NO,  HOW,  and 
WHY  response  buttons.  Experienced  mechanics,  who 
only  need  to  respond  to  the  conditions  outlined  on  the 
CTS  screens,  may  elect  to  use  YES  and  NO  buttons. 
Inexperienced  mechanics,  who  require  additional 
guidance,  may  elect  to  use  HOW  and  WHY  buttons. 
The  HOW  and  WHY  logic  is  layered,  so  that 
successive  invocation  of  HOW  will  lead  to  more 
detailed  explanation  than  given  at  the  previous  level. 
Upon  completion,  an  electronic  DA  Form  2404  with 
noted  deficiencies  is  automatically  generated.  When 
deficiencies  are  noted,  TED  automatically  links  to 
pertinent  sections  of  maintenance  and  repair  parts 
modules. 


plication  procedure  :  .  .  i  ■ _ ■ 


Figure  5:  Preliminary  Analysis  Screen 


o  Rapid  Functional  Assessment  (RFA).  The  RFA 
module  is  a  safety  procedure  to  quickly  determine 
whether  it  is  safe  to  attempt  to  start  the  engine.  A 
minimal  number  of  inspections-three  rotational  and 
four  lubricational-evaluate  the  mechanical  integrity  of 


the  engine's  internal  rotating  components.  RFA  is  an 
important  safety  check  because  it  minimizes  the 
potential  for  personal  injury  or  unnecessary  damage  to 
the  engine. 

o  Troubleshooting  by  Symptom.  Troubleshooting  by 
Symptom  opens  a  new  menu  screen  that  organizes  DS 
diagnostic  logic  by  terms  easily  recognized  by 
mechanics,  regardless  of  experience.  Symptoms 
include:  no  start,  low  power,  high  oil  consumption, 
engine  smokes,  metal  contamination,  quick  coast  down, 
idle  faults,  and  engine  shutdown.  Each  of  the  eight 
submodules  contains  diagnostic  logic  to  first  determine 
the  cause  of  the  faulty  symptom,  and  once  the  cause 
has  been  detected,  TED  will  link  to  the  appropriate 
maintenance  and  repair  parts  modules. 

o  Protective  Mode  (PM)  Troubleshooting.  The  ECU 
constantly  monitors  all  sensor  inputs  and  compares 
them  with  the  engine’s  established  parameters.  If  an 
input  is  out  of  tolerance,  the  ECU  initiates  one  of  four 
protective  mode  actions  to  prevent  damage  to  the 
engine.  Unfortunately  at  DS,  there  is  currently  no  way 
to  query  the  ECU  to  find  what  protective  mode,  if  any, 
has  been  invoked.  The  PM  module  first  checks 
whether  a  PM  condition  exists  and  if  so,  checks  for  the 
cause,  and  then  links  to  the  appropriate  maintenance 
and  repair  parts  modules. 

o  Maintenance  Procedures.  Maintenance  actions  for 
any  component  include  adjust,  repair,  remove,  and 
replace.  The  procedures  can  be  invoked  in  either 
browse  mode  or  data-driven  mode.  When  in  browse 
mode,  maintenance  procedures  are  manually  selected 
through  menus  and  submenus.  This  provides 
experienced  mechanics  the  flexibility  of  viewing  only 
the  procedures  that  they  need,  while  bypassing  familiar 
or  routine  tasks.  When  in  the  data-  driven  mode,  TED 
automatically  establishes  the  correct  links  to  all 
pertinent  maintenance  procedures  (and  to  sections  of 
the  repair  parts  manual).  The  maintenance  tasks  detail 
applicable  procedures  from  TM  9-2835-255-34  series. 

o  Repair  Parts  Special  Tool  Listing  (RPSTL).  In  lieu  of 
paper  RPSTLs  (TM  9-2350-264-24P1,  TM9-2520-276- 
34P,  and  TM  9-2835-255-34P),  the  TED  RPSTL  is 
electronically  generated.  All  required  information  is 
provided  so  that  parts  can  be  automatically  ordered  and 
filed  to  the  parts  request,  which  can  then  be  exported  to 
a  printer. 
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8,  Formal  User  Test 

During  the  week  of  15  to  21  August  1993,  an 
initial  field  test  of  the  TED  program  was  conducted  at 
Fort  Stuart,  GA.  Participating  in  the  test  were  30 
soldiers  from  the  Support  Squadron,  278th  Armored 
Cavalry  Regiment  and  771st  Maintenance  Company, 
176th  Maintenance  Battalion  of  the  Tennessee  Army 
National  Guard  (TNARNG).  Keeping  in  mind  the 
target  audience  (DS  mechanics),  the  test  had  two 
objectives:  first,  measure  how  accurately  and  quickly 
mechanics  could  identify  randomly  assigned  faults  on 
the  engine  using  TED  versus  using  TMs;  second, 
decide  if  the  program  was  soldier  friendly.  For  the  test, 
the  30  mechanics  were  divided  into  3  levels  of  10 
mechanics  each:  E1-E4,  E5,  and  E6-E7.  Because  the 
TNARNG  had  just  transitioned  to  the  MBT,  there  was 
a  lack  of  experience  on  the  engine.  The  test  was 
designed  by  Dr.  Malcolm  Taylor,  Chief  Statistician, 
ARL,  and  the  late  Dr.  Henry  Tingey,  University  of 
Delaware.  The  field  test  was  developed  to  test  the 
preliminary  analysis  and  no-start  modules  of  the  TED 
program. 

Each  mechanic  inspected  two  engines,  one  with 
TED  and  one  with  the  TMs.  The  engines  had  a  random 
number  of  faults  installed  from  a  randomized  list  of 
possible  faults.  There  was  a  1-hour  time  limit  for  each 
inspection.  An  observer,  with  a  score  card,  was  present 
with  each  mechanic  to  log  faults  and  the  times  that  each 
fault  was  located.  The  conditions  of  the  test 
approximated  the  actual  working  environment  of  the 
mechanics: 

-  A  DS  maintenance  bay  and  GHSS  were  available. 

-  TED  or  TMs  were  made  available  to  the  mechanics. 

-  Instructions  to  each  mechanic  were  to  inspect  the 
engine  and  determine  the  fault  causing  a  no-start 
condition.  Observers  provided  no  other  assistance  to 
the  mechanics. 

-  An  unrealistic,  yet  necessary  condition,required 
mechanics  to  be  situated  so  that  they  worked 
independently  without  any  intercommunications. 

Three  types  of  data  were  collected  during  the  field 
test:  first,  the  observer's  score  card  (mentioned 
previously),  which  served  as  the  basis  for  the  statistical 
analysis;  second,  a  questionnaire  completed  by  each 


mechanic,  which  allowed  him  to  express  his 
impressions  of  TED;  third,  each  observer  recorded 
personal  comments,  which  served  as  an  additional 
source  of  information  for  further  revisions. 

PRELIMINARY  RESULTS.  Although  the  TNARNG 
soldiers  had  very  little  engine  experience,  the  field  test 
results  show  a  definite  trend.  At  each  level,  TED 
outperformed  the  current  TM  procedures  (see  Table  1). 
TED  assisted  the  junior  enlisted  and  the  junior 
noncommissioned  officers  in  finding  at  least  twice  as 
many  faults  as  compared  to  the  TMs.  Note  that  even 
though  TED  is  designed  for  junior  mechanics,  senior 
mechanics  were  able  to  increase  their  efficiency  by 
using  TED.  Overall,  the  mechanics  demonstrated  a 
96%  increase  in  their  ability  to  efficiently  diagnose  the 
engine. 

MANUAL  TED 
FAULTS  FAULTS 


RANK  DETECTED  DETECTED 


El  -E4 

26% 

52% 

E5 

11% 

42% 

E6-E7 

42% 

56% 

OVERALL 

26% 

51% 

Table  1:  Preliminary  Test  Results 

The  ease  of  use  became  readily  apparent  to  the 
observers  during  the  initial  training  session.  Because 
many  of  the  mechanics  had  never  used  a  computer,  the 
observers  allocated  a  1-hour  training  block  for  each 
mechanic.  In  less  than  10  minutes,  mechanics  who  had 
never  used  a  computer  were  effectively  maneuvering 
through  the  software  and  hardware.  Soldier  acceptance 
was  also  unanimously  positive.  Both  computer-  and 
noncomputer-literate  mechanics  readily  accepted  TED 
as  the  preferred  tool  for  maintaining  the  engine.  Listed 
next  is  a  sample  of  the  soldiers'  comments: 

o  "TED  is  easy  to  use  and  understand." 

o  "TED  is  easy  to  use.  It'll  be  very  helpful  to  both 
experienced  and  nonexperienced  mechanics." 

o  "I  like  the  specific  guidance  that  it  provides;  it 
makes  it  easy  to  solve  problems." 
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o  "I  like  how  it  breaks  down  the  components  and 
explains  each  of  them;  it  provides  a  structured 
procedure." 

o  "This  will  cut  the  TI  (Technical  Inspection)  time 
dramatically;  it  pinpoints  the  areas  very  well.  It 
saves  time;  it’s  accurate,  compact,  and  easy  to  use." 

o  "Regardless  of  experience,  one  could  use  TED." 

o  "It  is  easier  than  using  the  Tms." 

o  "TED  is  my  buddy." 

9.  Related  Efforts 

Two  other  features  that  are  linked  to  the  TED 
program  include  the  diagnostic  intelligent  tutoring 
system  (DITS)  and  the  ABOB.  Although  initially 
separate  projects,  both  have  come  to  live  under  the 
TED  umbrella  and  become  integral  parts  of  TED. 

DITS  is  an  embedded  tutorial  that  covers  basic 
maintenance  procedures,  theory  of  engine  operations, 
and  guidance  in  such  tasks  as  connecting  the  GHSS  and 
using  a  multimeter.  Using  interactive  review  and 
troubleshooting  modules,  mechanics  can  hone  their 
diagnostic  skills  in  a  field  environment.  DITS,  a 
diagnostic  trainer,  complements  TED,  a  diagnostic  tool, 
by  providing  mechanics  a  complete  system. 

The  ABOB,  developed  by  Dr.  Mark  Kregel  from 
ARL,  is  an  automated  version  of  the  breakout  box 
(BOB),  which  is  a  diagnostic  tool  that  is  currently  in 
the  field.  Mechanics  employ  the  BOB,  connected  to 
the  vehicle’s  electronic  control  unit,  as  an  alternate 
troubleshooting  method  to  determine  the  operational 
status  of  the  engine.  The  ABOB  automates  the  manual 
tasks  associate  with  the  BOB  by  providing 
instantaneous  access  to  all  of  the  engine's  voltage 
signals. 

The  ABOB  contains  an  electronic  circuit  capable 
of  reading  128  channels  in  a  fraction  of  a  second. 
These  signals  are  passed  to  the  CTS  through  a 
standard  serial  port.  The  ABOB  can  be  used  with  or 
without  TED  to  display  voltages  on  the  CTS  screen  in 
either  numerical  or  graphical  format.  When  TED  is  run 
with  the  ABOB,  signals  can  be  automatically 
monitored,  and  when  a  fault  occurs,  mechanics  will  be 
notified  of  the  problem. 


10.  Future  Efforts 

Future  improvements  of  the  TED  program  include 
the  incorporation  of  approximate  reasoning  methods  to 
allow  better  representation  and  integration  of  sensor 
data.  Before  the  TED  program,  in  particular  the 
invention  of  the  ABOB,  the  ability  to  monitor  more 
than  a  single  sensor  reading  on  the  MBT  engine  did  not 
exist.  More  important,  the  ability  to  determine 
correlations  between  changing  sensor  information  and 
the  possible  inference  of  diagnostic  and/or  prognostic 
information  did  not  exist.  This  area  lends  itself  to 
research  in  the  application  of  fuzzy  logic  and  neural 
nets. 
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